home *** CD-ROM | disk | FTP | other *** search
- This is only a rough draft - Megan 04/08/92
-
- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- Multiplexing SNMP Agents BOF
-
- These are the minutes of the Multiplexing SNMP agent BOF held at the
- Spring 1992 IETF meeting in San Diego, California.
-
- The meeting was chaired by Karl Auerbach and minutes were taken by Ed
- Alcoff.
-
- The meeting began with a quick pair of slides restating the purpose
- of the BOF and a straw man proposal:
-
- ======================================================================
- SLIDE 1
-
- The purpose of this BOF is to determine:
-
- a) Whether SMUX or DPI are adequate.
-
- b) Whether the proxy capabilities in secure SNMP are adequate.
-
- c) If neither a) nor b) are adequate, why not?
- In other words, what sorts of functions do users
- think they need from a multiplexing SNMP agent?
-
- d) What sort of solutions might exist
-
- i) If the solutions are limited to the Unix operating
- system?
-
- ii) If the solutions are generalized to cover Unix
- and other environments?
-
- Goal:
-
- The goal of this BOF is to make an inquiry regarding the scope of the
- issue and the range of potential solutions.
- ======================================================================
-
-
- ======================================================================
- SLIDE 2
-
- Straw man:
-
- To begin the discussion, here are some criteria I think might be
- appropriate for a multiplexing agent:
-
- 1. New MIB sub-trees may be attached *and* detached at any time.
-
- 2. Sub-trees may not be nested. In other words, an attached sub-tree
- may not have dynamically attached lower level sub-trees.
-
- 3. The master agent must not be required to have a priori knowledge
- of what is in the subtrees. (In other words, that agent ought to
- be able to accept any arbitrary subtree.)
-
- 4. Get-next must work across subtree boundaries.
-
- 6. Get-requests and Get-next requests must be allowed to have
- varBind entries which refer to elements in multiple subtrees.
- In other words, a single get/getnext ought to be able to fetch
- stuff in multiple sub-trees.
-
- 7. A set-request ought to be able to contain varBind entries which
- refer to elements in multiple subtrees. And the "as if
- simultaneous" requirement must be preserved across subtrees.
-
- This one we might want to debate.
-
- 8. The multiplexing scheme must be robust despite sub-agent failures.
- (I.e. a request ought not hang forever if a sub-agent is non-responsive.)
-
- 9. The multiplexing scheme need only support sub-agents on the same
- machine as the primary agent.
-
- 10. Multi-agent/multi-protocol capability: The multiplexing protocol
- ought to be designed so that a given subordinate agent could
- support multiple superior agents. In addition, the protocol ought
- to be rich enough that those superior agents aren't just SNMP
- agents.
- ======================================================================
-
-
- DISCUSSION:
-
- The BOF started with discussion of the "10" points listed on slide #2.
-
- 1. No one strongly disputed the need for dynamic growth or
- contraction of the MIB tree.
-
- 2. It was pointed out that one may want to have different instances
- of a variable or group "owned" by a different sub-agents. For
- example, each row of a table may be provided by a separate sub-agent
- rather than having the entire table provided by a single sub-agent.
- This appears to be a useful point of view. It is, however,
- significantly at odds with previous thinking in which all instances
- of any given variable would be "owned" by a single sub-agent.
-
- 3. A model was proposed in which there would be multiple,
- independent sub-agents rather than a single master multiplexing SNMP
- agent. In this new model, each agent would emit a start-up trap
- announcing its service address. A management station would then
- address independent SNMP queries to the appropriate agent.
-
- 4. Problem with both SMUX & DPI was noted: Because of the
- uncoordinated activities of the various sub-agents, the correlation
- of sysUpTime with sub-agent derived information may be weak and may
- vary unpredictably. It may be difficult, if not impossible, to
- provide a useful correlation between time stamps (such as sysUpTime)
- and readings of management variables.
-
- 5. A concern was raised whether effective network management
- requires that a management station be able to issue an SNMP
- varBindList which has items spanning MIB subtrees owned by separate
- sub-agents.
-
- One participant asked whether this was a non-issue. In particular,
- does it really matter whether a query is split among agents (or
- sub-agents) by the SNMP manager station itself or by a master agent?
-
- In further discussion, it was suggested that since the agent is
- "closer" to the sub-agents it is in a better position to know how to
- best partition queries. Partitioning by the agent also has the
- advantage that get-next semantics can be preserved even where the
- next lexiographic item lies across a sub-agent boundary.
-
- Another participant commented that whenever a MIB is partitioned
- among sub-agents, it is necessary to replicate at least the System
- group in each partition. Thus it would be possible to retrieve
- timestamps which are correlated with the data values.
-
- A question was raised whether the sysUpTime value of the various
- partitions need to be synchronized. A well known pragmatist answered
- that on most hosts, it is quite easy to keep the various instances of
- sysUpTime fairly well synchronized. This left unanswered the
- question whether such synchronization is needed when the sub-agents
- reside on separate processors.
-
- 6. Looking to practice, do people actually issue queries which deal
- with logically separate information bases (each of which presumably
- would be handled by a separate sub-agent)?
-
- On one hand would one ever realistically want to ask about routing
- tables and sendmail in the same SNMP query? Probably not.
-
- On the other hand, one could conceive of a query which tried to
- correlate network traffic load with changes in routing topology. And
- it is not unreasonable to believe that load measurement and routing
- topology would be maintained in separate sub-agents.
-
- It was pointed out that many SNMP managers do not recognize the
- notion that a single managed device may contain multiple SNMP
- entities. Consequently, many managers today present such devices on
- the user interface as if they were multiple, separate devices.
-
- 7. It was asked to what extent existing multiplexed SNMP agents
- enforce the "as if simultaneous" atomic requirements of SNMP
- Set-Requests.
-
- It appears that a significant number of existing multiplexed agents
- do not make this guarantee. This has not, to date, appeared to have
- caused any operational difficulties. However, this may be the result
- of simplistic user interfaces which limit set-requests to one value,
- proprietary MIBs which are designed so as to avoid the need for
- atomic "sets", or to adolescent tools which do not yet push
- Set-Requests very hard.
-
- 8. There was discussion regarding the implementation burden on
- sub-agent writers. At a minimum, there was a desire to avoid
- encoding and decoding ASN.1/BER. Alternatives suggested were XDR or
- simplified BER. If the agent-sub-agent interface did not cross
- machine boundaries then one could even use internal, host specific
- data formats.
-
- Some people wanted to go further and isolate sub-agents from the
- issues of object naming, object instancing, and lexiographic
- ordering. It was hoped that the agent-to-sub-agent interface could
- be hidden behind a clean programming API. There was no consensus,
- however, whether this is feasible unless done in the context of a
- specific operating system.
-
- 9. DEC, HP, IBM, and Peer Networks quickly described their own
- methods of dealing with some or all of the issues.
-
- 10. Marshall Rose described a means using the Secure SNMP protocols
- and MIB to partition the management variable space among multiple
- sub-agents. Each "party" would be mapped to a separate sub-agent.
-
- It was pointed out that this is really a variation of the "completely
- disjoint agent" method #3, above.
-
- SUMMARY:
-
- There is strong interest in multiplexing SNMP agents. A number of
- multiplexing agents or extensible agents have been constructed. And
- various attendees have built multi-protocol agents and managers.
-
- The requirements are not yet well understood. In particular, a
- significant number of attendees were of the opinion that it is not
- necessary to preserve full SNMP query semantics across sub-agent
- boundaries or that it is acceptable for an agent to fail to honor the
- "as it simultaneous" and atomic properties of SET requests.
-
- Using the proxy facility of the forthcoming secure SNMP would easily
- and directly provide a means to divide MIBs among separate
- sub-agents. But it would require that a management station be aware
- of the MIB partions.
-
-
-